In the realm of computing, the relationship that drives most useful distributed applications is the client-server relationship. The interaction between client and server allows most computing beyond an unconnected, single computer. The client-server relationship defines an architecture in which a user's computer, which may be a personal computer (PC), may be the client machine or entity requesting something from a server, which is the supplying machine or entity. However, a PC may also operate as the server side of the client-server relationship. Both are typically connected via some kind of network, such as a local area network (LAN) or wide area network (WAN).
In the client-server model, the client typically processes the user interface (WINDOWS™, MACINTOSH™, etc.) and may perform some or all of the application processing. Servers may range in capacity from high-end PCs to mainframes. A database server typically maintains databases and processes requests from the client to extract data from or to update the database. An application server, which is a software server, typically provides additional business processing for the clients.
While many client-server models are now commonly referred to as “Web based” and/or “Web enabled,” the architecture is conceptually the same. Users' PCs may still be clients, and there are tens of thousands of Web servers throughout the Internet delivering Web pages and other functionality. On the Web, the client typically runs the browser and, just like legacy client/server systems, can perform a little or a lot of processing, such as simply displaying hypertext mark-up language (HTML) pages, processing embedded scripts, or considerable processing with JAVA™ applets. A myriad of browser plug-ins provide all sorts of possibilities for client processing.
FIG. 1 is a block diagram illustrating typical client-server system 10. Server 100, which may be a network server, a Web server, or the like, hosts a remote application that is available to clients 101-104. As each of clients 101-104 desires to access the remote application, a connection is made between the client and server 100. The client, such as client 101, issues a request to server 100 to access the remote application. Server 100 activates the remote application, performs whatever logic calculations the remote application is designed to perform and then transmits the results back to client 101. This relationship is a request-response relationship. For example, if server 100 is a Web server and client 101 is a Web browser. The user at client 101 enters a Web address into client 101. Client 101 issues a request for the page index for the Web address to server 100. When server 100 receives the request, it processes the necessary logic to create the Hypertext Markup Language (HTML) file the makes up the requested Web page, or accesses the stored HTML file, and transmits it back to client 101. Client 101 then displays the HTML file to the user.
During the early days of the Internet, its client-server architecture was used as a communications system funded and built by researchers for military use. This Internet, originally known as ARPANET, was embraced by the research and academic communities as a mechanism for scientists to share and collaborate with other scientists. This collaborative network quickly evolved into the information superhighway of commerce and communication that has been a key part of personal and business life in the last 5-10 years. The Internet explosion was due, in part, to the development of the Web and graphically-based Web browsers, which facilitated a more graphically-oriented, multimedia system that uses the infrastructure of the Internet to provide information in a graphical, visual, and interactive manner that appeals to a wider audience of consumers seeking instant gratification.
As the technology underlying transmission bandwidth has grown in conjunction with the accessibility to such increasing transmission bandwidth, a new paradigm for the old idea of Internet collaboration is emerging that takes advantage of the modern graphical, visual world. This new paradigm is also driven by the advance in real-time or time-sensitive data transmission technology, such as Voice over Internet Protocol (VoIP) technology, and the like. Non-Internet videoconferencing, which has generally not been able to completely supplant teleconferencing as a viable means for reliable communications, is slowly fading away in favor of Internet-driven technology, such as collaborative electronic meetings. Services, such as WEBEX COMMUNICATIONS, INC.'S, WEBEX™ electronic meeting or collaboration services offer the ability for users to connect, at least initially, across the Internet to share voice, video, and data in real time for meetings, presentations, training, or the like.
In such collaborative meeting environments, a virtual meeting room typically is made up of several meeting objects which are generally containers for presentation information, such as slides, video, audio, documents, computer applications, and the like, that are themselves contained within the container of the meeting room. These meeting objects are typically placed into a static arrangement on the actual electronic meeting interface. Therefore, chat objects may be set on the bottom right of each meeting interface screen, while slide or other main presentation objects are set on the left half of each meeting interface screen. Once the meeting begins, each of the meeting participants, both presenters and viewers, usually see the same static meeting interface with the presenters information loaded thereon.
One example of an electronic collaboration application and system is MACROMEDIA INC.'s BREEZE™ rich Internet communication system (RICS). A RICS system is an application and its underlying infrastructure that implements an electronic collaboration system that shares and collaborates multimedia information, such as audio, video, and data. Because of the collaboration of such multimedia information in a real time system, it is advantageous to manage any particular electronic meeting on a single computer or collaboration server. However, managing an electronic meeting on a single collaboration server provides a finite limit to the number of meeting participants that may experience the electronic meeting.
This type of single-server meeting implementation leverages a direct client-server architecture. Referring back to FIG. 1, the illustration of client-server system 10 provides an accurate depiction of the single-server meeting implementation. A client computer, typically the computer used by a meeting participant, such as client 102, connects directly into the central collaboration server, server 100, managing the meeting. The central collaboration server, server 100, has a finite limit to the number of connections that it can efficiently manage for the meeting. Thus, without a dedicated, proprietary network, electronic meetings have been limited in capacity.
A logical extension to the single-server, client-server architecture has involved the deployment of additional servers that maintain high speed communication with the main server, but that are located in remote areas closer to the clients. The remote servers' role is to take the load from the central server and distribute it closer to the clients. Content Delivery Networks (CDN) typically employ servers on the edges of the network. These servers, referred to typically as edge servers maintain copies of the content that can be regionally distributed to the clients within that edge server's region. Thus, a client in Dallas, Tex. accessing a music downloading system, that employs an edge-driven CDN, may download a particular song from an edge server located in Austin, Tex., while a client in San Francisco, Calif., of the same music downloading system may download the same song from an edge server located in Palo Alto, Calif. Both clients access the same system, using the same Uniform Resource Locator (URL), but then download the content from regionally different edge servers.
One such CDN is operated by AKAMAI TECHNOLOGIES, INC. AKAMAI employs its EDGESUITE™ Delivery Service to provide localized delivery of content, to more-efficiently manage a content deliver system. In application, the edge servers in the CDN each store copies of the available content. Thus, when a local client requests a particular document from the central system, the local edge server will be tasked with delivering that content. This system relieves the central system from performing too much copying and delivering, which may adversely affect the bandwidth or efficiency performance of the central system.
FIG. 2 is a block diagram illustrating edge network 20. When employed as a CDN, the central access point is maintained by central server 200, while edge servers 201 and 202 each have a copy of the content that is available through the CDN. Depending on their location, clients 203-208 may access the content through local, edge servers 201 or 202. For example, clients 203-205 access the CDN through edge server 201, while clients 206-208 access through edge server 202. If client 206 wishes to obtain a piece of content, it negotiates with central server 200 for the content, which may be downloaded through edge server 202. If client 205 wishes to obtain the same piece of content, it also negotiates for the content with central server 200, which may be downloaded through edge server 201. By relieving central server 200 of the tasks of streaming the data for the content to both clients 205 and 206, it is free to server more of the clients directly in negotiating for content.
FIG. 2 may also represent a multi-server collaboration system of the type operated by WEBEX™. WEBEX™ uses multiple servers to manage and maintain its electronic meetings. Because of its proprietary network, it is more easily capable of managing a single meeting over multiple servers. For example, a copy of everything supporting an electronic meeting may be stored on each of central server 200 and edge servers 203-208. Thus, as client 208 logs into edge server 202 to join the single electronic meeting with clients 203-207, its participation in the meeting is managed by edge server 202. Similarly, client 204, logs onto the meeting through edge server 201. Both of clients 204 and 208 are participating in the same meeting. However, the meeting is managed by both edge servers 201 and 202. Another client (not shown) may even connect directly to central server 200 to participate in the meeting because central server 200 also maintains a copy of all of the information necessary to run the meeting.
While the proprietary network of WEBEX™ allows for such a multi-server management, management of the complexity of an electronic meeting using the Internet as its infrastructure has typically been limited to a single-server system. Such systems, as noted above, are limited in the number of participants it can support at any given time.